Design Patterns גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

Transcription

1 Design Patterns גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

2 2 Problem: Reusability in OO Designing OO software is hard, and designing reusable OO software is even harder: Software should be specific at the problem on hand, but It should be general enough to address changes and future requirements My component is reusable but it needs some modification before being reused

3 3 Roadmap When faced with a new problem, where do you look for inspiration? Most people look to solutions of previous problems that have similar characteristics This insight is what is behind design patterns: A Collections of proven ways to structure the relationships between objects in the pursuit of a given objective

4 4 Patterns Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million time over without ever doing it the same way twice [Christopher Alexander / The Timeless Way of Building]

5 5 Patterns in Physical Architecture (Patterns set the Design Language) When a room has a window with a view, the window becomes a focal point: people are attracted to the window and want to look through it. The furniture in the room creates a second focal point: everyone is attracted toward whatever point the furniture aims them at (usually the center of the room or a TV). This makes people feel uncomfortable. They want to look out the window, and toward the other focus at the same time. If you rearrange the furniture, so that its focal point becomes the window, then everyone will suddenly notice that the room is much more comfortable. [Leonard Budney, Amazon.com review of The Timeless Way of Building ]

6 6 Example: Building a House

7 7 Example: Building a House Pattern

8 8 Example: Building a House Reality Pattern

9 9 Example: Building a House Reality Pattern

10 10 Inspiration, and a Vocabulary Design patterns speed the process of finding a solution, by eliminating the need to reinvent wellknown and proven solutions Image from: blogs.technet.com Just as important, design patterns provide a vocabulary with which to discuss the space of possible design choices This vocabulary is termed a pattern language

11 11 Relationship to Dependency and Visibility Many patterns are involved with the concepts of dependency we introduced in the previous chapter Determining where strong dependencies are necessary And how to weaken dependencies whenever possible

12 12 A Simple Example: The Adapter An adapter is used to connect: A client (an object that needs a service) With a server (an object that provides the service) The client requires a certain interface, and while the server provides the necessary functionality, it does not support the interface The adapter changes the interface, without actually doing the work

13 13 An Example Adapter class MyCollection implements Collection { } public boolean isempty () { return data.count() == 0; } public int size () { return data.count(); } public void addelement (Object newelement) {data.add(newelement); } public boolean containselement (Object test) { return data.find(test)!= null; } public Object findelement (Object test) { return data.find(test); } private DataBox data = new DataBox(); DataBox is some collection that does not support the Collection interface Adapters are often needed to connect software from different vendors

14 14 The Gang of Four Brought design patterns into the mainstream Authors known as the Gang of Four (GoF) Focuses on descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context

15 15 Describing Patterns Patterns themselves have developed their own vocabulary for description: Name: The term that will be used to describe the pattern Synopsis: Short description of the problem the pattern will solve Forces: Requirements, considerations, or necessary conditions Solution: The essence of the solution Counterforces: Reasons for not using the pattern Related patterns: Possible alternatives in the design

16 16 Example Patterns Iterator Software Factory Strategy Singleton Composite Decorator Double-Dispatch Flyweight Proxy Facade Observer

17 17 Iterator Problem: How do you provide a client access to elements in a collection, without exposing the structure of the collection Solution: Allow clients to manipulate an object that can return the current value and move to the next element in the collection Example: Enumerators in Java interface Enumerator { public boolean hasmoreelements(); public Object nextelement(); } Enumeator e =...; while (e.hasmoreelements) { Object val = e.nextelement();... } The pattern applies, even if the interface is changed

18 18 Software Factory Problem: How do you simplify the manipulation of many different implementations of the same interface (i.e., iterators) Solution: Hide creation within a method, have the method declare a return type that is more general than its actual return type: class SortedList {... Enumerator elements () { return new SortedListEnumerator(); }... private class SortedListEnumerator implements Enumerator {... } } The method is the factory. Users don't need to know the exact type the factory returns, only the declared type The factory could even return different types, depending upon circumstances

19 19 Strategy Problem: Allow the client the choice of many alternatives, but each is complex, and you don't want to include code for all Solution: Make many implementations of the same interface, and allow the client to select one and give it back to you Example: The layout managers in AWT. Several different layout managers are implemented, and the designer selects and creates one Gives the designer flexibility, keeps the code size down

20 20 Singleton Problem: You want to ensure that there is never more than one instance of a given class Solution: Make the constructor private, have a method that returns just one instance, which is held inside the class itself class SingletonClass { public: static SingletonClass * oneandonly () { return theone; } private: static SingletonClass * theone; SingletonClass () {... } }; // static initialization SingletonClass * SingletonClass::theOne = new SingletonClass();

21 21 Composite Problem: How do you facilitate creation of complex systems from simple parts? Solution: Provide a few simple components, and a system to compose components (simple or otherwise) into new components Arithmetic expressions are an example, so are type systems, or the nesting of panels within panels in the Java AWT API

22 22 Decorator (Filter, Wrapper) Problem: Allow functionally to be layered around an abstraction, but still dynamically changeable Solution: Combine inheritance and composition. By making an object that both subclasses from anther class and holds an instance of the class, can add new behavior while referring all other behavior to the original class Example Input Streams in the Java I/O System: // A buffered input stream is-an input stream class BufferedInputStream extends InputStream { } public BufferedInputStream (InputStream s) { data = s; }... // and a buffered input stream has-an input stream private InputStream data; An instance of BufferedInputStream can wrap around any other type of InputStream, and simply adds a little bit new functionality

23 23 Example: Decorator Although paintings can be hung on a wall with or without frames, frames are often added, and it is the frame which is actually hung on the wall: Prior to hanging, the paintings may be matted and framed, with the painting, matting, and frame forming a single visual component

24 24 Double Dispatch (Multiple Polymorphism) Problem: You have variation in two or more polymorphic variables. Solution: Make each a receiver in turn, each message ties down one source of variation Example: suppose we have a hierarchy of Shapes (Triangle, Square) and Device (Printer, Terminal). Two variables, one a Shape and one a Device. First, pass: Shape ashape =... ; Device adevice =...; adevice.display(ashape); function Printer.display (Shape ashape) begin ashape.displayonprinter (self); end; function Terminal.display (Shape ashape) begin ashape.displayonterminal (self); end; One message fixes the device, but how to fix the shape?

25 25 Double Dispatch, continued Each subclass of Shape must implement methods for each output device: class Triangle : public Shape { public: Triangle (Point, Point, Point); //... virtual void displayonprinter (Printer); virtual void displayonterminal (Terminal); //... private: Point p1, p2, p3; }; void Triangle.displayOnPrinter (Printer p) { // printer-specific code to display triangle } void Triangle.displayOnTerminal (Terminal t) { // terminal-specific code to display triangle }

26 26 Flyweight Problem: Designing objects down to the lowest levels of system granularity provides optimal flexibility, but can be unacceptably expensive in terms of performance and memory usage Solution: Use sharing to support large numbers of fine-grained objects efficiently one two common data three

27 27 Proxy Problem: How to hide unimportant communication details, such as a network, from the client Solution: A proxy uses the interface that the client expects, but passes messages over the network to the server, gets back the response, and passes it to the client. The client is therefore hidden from the network details Client Intermediary Server Similar in some ways to adaptor, but here the intermediary and the server can have the same interface

28 28 Facade Problem: Actual work is performed by two or more objects, but you want to hide this level of complexity from the client Solution: Create a facade object that receives the messages, but passes commands on to the workers for completion Worker 1 Client Intermediary Worker 2 Worker3 Also similar to adapter and proxy

29 29 Observer Problem: How do you dynamically (at run time) add and remove connections between objects Solution: An Observer Manager (OM) implements the following protocol: I want to observe X The OM will keep track of who is watching who Tell everybody who is observing me that I have changed The OM can then tell everybody that an object has changed ON ON This way, neither the observer nor the observed object need know the existence of each other ON OFF OFF OFF

30 30 Observer Subject represents the core (or independent or common or engine) abstraction Observer represents the variable (or dependent or optional or user interface) abstraction The Subject prompts the Observer objects to do their thing. Each Observer can call back to the Subject as needed.

31 31 Patterns and Frameworks Both are ways of describing and documenting solutions to common problems. Frameworks are more shrink-wrapped, ready for immediate use Patterns are more abstract many patterns are involved in the solution of one problem

32 32 Benefits of Design Patterns Design pattern for building reusable software Design pattern as a unified standard for system development Design pattern for minimizing time consumption in development Design pattern as protocol for team communication Design pattern for minimizing team member capability gap